黑色好看版 - 傳送門

何謂一個好的系統呢 ?

為什麼會問這個問題呢 ?

因為事實上這個是我原本想要撰寫的主題。咱們工程師在開發系統，所學習的大部份的技術，基本上都是為了追求『建立一個好的系統』，然後我本來想將建立一個好的系統的知識點，建立成一個 30 天的知識集，但就算進行精簡化，也很難進行有深度的探討。

因此後來才有了這 30 天這個主題 :

30天之從 0 至 1 盡可能的建立一個好的系統 (性能基礎篇)

接下來我們來說說，上述的主題『性能』，在一個好的系統中，是那一個部份。

何謂一個好的系統呢 ?

這個主題事實上非常的抽象與盤大，問十個人可能有十種答案，在這裡筆者將來說明心中理想的系統。

一個好的系統我覺得最重要的一點為 :

要有人用

這個是我覺得是最重要的一點，如果沒有人用，除非你裡面的技術是可以改變世界的，不然基本上是沒啥價值性的，不論是科學或是商業價值。

『要有人用』這個基本上咱們搞技術的除非你和老闆是好麻吉，不然事實上很難干涉行銷策略這個層級的事情，所以這一塊咱們先不管。

不過也不代表我們不用學這個領域的知識。

你的知識越廣，就越不會被固定領域知識僵固，並且更能幫助你突然領域的深度。

忘了是誰說的，不過我很喜歡這句話。

不過這句話我覺的有個前提假設 :

不過你要先有一把刀，你才能去開拓世界。

也就是說如果你沒有先在你的領域打個底，那麼你也沒有本事將從其它領域學到的東西，融入你的領域。

某些方面，我覺得學程式語言就如同上面這一句話一樣。

在有人用的情況下，何謂一個好的系統呢 ?

我覺得一個好的系統只有一個重點 :

讓雙方愉悅

這裡雙方是指『用戶』與『公司』。

• 能夠讓使用者覺得好用，用起來就是愉悅兩字 (用戶愉悅)。
• 能夠以最少的資源(機器)做最多的事情 (公司愉悅)。
• 能夠讓開發人員未來花越少的時間在維護 (公司愉悅)。
• 安全 (用戶與公司都愉悅)。

能夠讓使用者覺得好用，用起來就是愉悅兩字 (用戶愉悅)

• 畫面讓人覺得愉悅。(設計)
• 畫面操作讓人覺得愉悅。(UI/UX、性能)
• 不會一下可以用，一下不能用。(可用性)

總結一句話 :

使用者不愉悅，我們就沒錢

能夠以最少的資源(機器)做最多的事情 (公司愉悅)

• 能以最少的機器服務最多的客官。(性能)
• 在多的客官，咱們都要能 hold 的住。(性能)

但這個要求事實上有一個前提假設，那就是要符合，讓使用者愉悅這特性，也就是說不會一下子可以用，一下不能用，不然會客戶會生氣的。

總結一句話 :

反正就是要省錢

能夠讓開發人員未來花越少的時間在維護 (公司愉悅)

時間就是金錢，省了開發人員的時間，就是省了錢。

• 不要未來 bug 一堆，讓開發人員花時間抓。(測試)
• 不要要抓 bug 時，花開發人員一堆時間。(log 機制)
• 不要一個正常的需求來了，就大部份程式要重寫。(設計模式、軟體工程)
• 不要光發佈或測試就花了一整天的時間。(CI/CD、測試)

總結一句話 :

時間就是金錢

安全 (用戶與公司都愉悅)

這個東東事實上非常的重要，資安沒做好，你是賠了時間與金錢

• 被駭客要 $$。
• 被駭客打爛系統，花時間回復。
• 被駭客打爛系統，導致系統不能用，使用者不愉悅。

轉化成軟體工程領域名詞

假設將上面那好的系統要求，轉成軟體工程領域大概就會變的如下:

最基本上就是分以前後端，並且後端部份又分為以下幾個 :

• 性能
• 可用
• 擴展
• 維護性
• 安全

但是我不算是很喜歡這種類型的分類，這些名詞太讓人覺得有太的想法分支。

假設有一個系統，它現在可以處理每秒 qps 大約有一百萬上下，你會稱它為高性能嗎 ? 這樣有點抽像，那就假設它是 fb 的系統，你會稱它為高性能嗎 ?

有些人可能會覺得，嗯它可以處理那麼多的量，它應該算高性能。

但是有些人卻覺得不會，因為它們可能用了很多機器。

嗯這就是高性能一詞的問題。

一個詞可能會讓人有多種解讀，例如我就想到下列三種 :

• 一個系統可以處理非常大量的資料，所以它是高性能的。
• 一個系統以最少的資源處理最多的事，所以它是高性能的。
• 一個系統處理一件事情，非常快。

我覺得正解應該是第二句話，但是高性能會讓人想到三種解讀，所以我不太喜歡直接使用高性能這個詞。

結論

本篇文章我們簡單的探討了一個問題 :

何謂一個好的系統呢 ?

而接下來的 30 天，咱們就要針對以越少的資源，做越多的事情這個好的要點，來進行深入的探討。

以越少的機器，做越多的事情，也就是所謂的『性能』

筆者會選擇以性能為主題，有主要幾個原因 :

首先第一個，因為我想。

在來第二點，大部份的文章以高性能為主軸的文章，都是『系統如何處理大流量、大併發』，然後會發現大部份都是以分散式為主，但是如果只是以多開機器來處理這些問，我不覺得是高性能。所以這裡才能打算寫個 30 篇的『我覺得高性能的系統』為主題。

再來是很多初學者，在學習如何處理大流量時，大部份都是直接跳往往分散式架構來處理，但咱覺得這是錯的。因為如果你單機處理不好，那我不會相信你架出來的分散式架構性能會多好。

最後這三十天仍然是以『一個好的系統』為主題的原因在於，這才是我們學習技術的出發點。希望未來有時間還可以針對不同的地方來進行深入的探討。

接下來就開始吧。

注意事項

這 30 天的文章，所學習的東西，是幫助你可以開發一個『更好』的系統，所以它有一個前提假設那就是你需要的功能已經開發出了。如果只是開發功能就已經卡很久了，那這時還一直分心花很多時間來追求『更好』，那我覺得你一定會被老闆 fired 掉的。

追求『更好』不是壞事，但是不要還不會走路就想飛，這是人生的大忌喔。